Generally, computer systems have a mechanism in which when an event involving intervention of software occurs at peripheral hardware, the peripheral hardware sends an interrupt request to a processor to suspend execution of a program being executed at that moment and to start an interrupt processing program.
On the other hand, recent processors have their performance remarkably enhanced by adopting, e.g., the following mechanisms a-c.
a. Cache memories
b. Many registers
c. Branch prediction mechanisms
However, these mechanisms exhibit a relatively low performance to processing, such as interrupt processing, which would change control flow at unpredictable timing.
On the other hand, in high-speed communication mechanisms in which interrupts could occur, e.g., every 12 μsec, such as so-called gigabit Ethernet (registered trademark), interrupt requests occur highly frequently. For example, in a case of receiving 1500-bytes packets at a communication rate of 1 Gbps, each packet is received every 12 microseconds. In a case where an ordinary hardware configuration is adopted in which an interrupt is originated every time a packet is received, interrupt processing must be performed every 12 microseconds.
Further, even in a system, such as a set-top box, in which many interrupt request originating sources must be stored internally, a ratio of a time consumed for interrupt processing to a total processing time tends to increase.
If interrupt request occurring intervals are predictable, this problem can be overcome by polling of a timer device by an operating system. This configuration is disclosed in, e.g., Non-Patent Document 1 (Mohit Aron and Peter Druschel, Soft Timers: Efficient Microsecond Software Timer Support for Network Processing, ACM Transactions on Computer Systems, Vol. 18, No. 3, August 2000).
However, such a technique is not applicable to interrupt request originating sources in which interrupt request occurring intervals are not predictable. The problem that the overhead increases with increasing interrupt occurring frequency would not only lead to a problem involving individual operating systems (OSs), but also impose a serious problem on partition management software that executes OS scheduling for concurrently operating a plurality of OSs in a single system.
In a case where a plurality of OSs are installed in a single system, processes executed by the OSs utilize hardware common to the system, i.e., a CPU, a memory, and the like, and thus it is required to execute the processes by the OSs while switching them time-sequentially. Partition management software executes such OS scheduling. Partitioning is a process corresponding to each of the OSs.
For example, assuming that two OS (α) and OS (β) reside together in a single system, and that a process of the OS (α) is designated a partition A and a process of the OS (β) is designated a partition B, then the partition management software determines an execution schedule for the partitions A and B, and executes the processes of the OSs on the basis of the determined schedule.
Thus, in an environment in which a plurality of OSs operate in a single system, in a case where an interrupt process can be executed only by the OS (α) operating in a particular partition, and in a case where a partition operating at the time of an interrupt request is the partition (B) of the OS (β) that cannot accommodate the interrupt process, a process is performed, in which the processing of the partition (B) is suspended; the interrupt process is executed by applying the OS (α); and the processing of the partition (B) is resumed after the interrupt process is completed. Thus, in processing interrupt requests, partition switching is to take place frequently.
Further, as a conventional partition management scheme, there is a configuration in which execution timings of partitions corresponding to OSs under management are determined irrespective of the occurrence of interrupts. In such a scheme, in a case where an interrupt request occurs, a partition corresponding to the interrupt request is to be set, without changing the already scheduled partitions corresponding to the OSs under management. In a case where an already scheduled partition dwells for a long time period, an interrupt request process may have to wait for a long time until its execution is started.
Thus, in the conventional partition management scheme that gives priority to the processes (partitions) of OSs under management, and thus keeps an interrupt request process waiting until there is an empty time slot between the processes (partitions) of the OSs under management, in a case where there is an interrupt request originating source demanding a stringent response time, an interrupt request process cannot be executed properly, making it likely to cause data processing error such as communication error.